What changed

Added a "Confirming SSO enforcement is active" verification paragraph to the "What happens when SSO is enabled" section of docs/single-sign-on.md. The new paragraph tells admins how to verify that Clay support has activated SSO for their workspace: open a private/incognito browser, enter a company email, click Continue — if SSO is active they'll be redirected to their IdP.

Why

An Enterprise customer (Komodo Health) with SSO already set up asked: "We have SSO set up but how can I confirm that SSO is required in our Clay set up?" (Intercom conversation 215475012286586). Fin did not handle this — a human support rep answered. The existing SSO doc describes what happens when SSO is enabled (domain-based browser redirect) and describes the sign-in flow, but does not include an explicit verification step an admin can use to confirm SSO activation is complete. This was the specific gap that prevented Fin from answering directly.

The same conversation also asked about SCIM availability — that's already covered in the "User provisioning" section ("Clay does not currently support SCIM provisioning"), so no change needed there.

Source link(s)

• Intercom conversation: https://app.intercom.com/a/inbox/w28k1kwz/inbox/conversation/215475012286586
• Slack thread (linked from Intercom): https://clay-hq.slack.com/archives/C0A7UM0LNBZ/p1783541797682949
• Verifier verdict (SSO browser-redirect behavior): PASS — clay-base/apps/api/v3/auth/services/auth.service.ts and clay-base/apps/frontend/src/routes/LoginPage.tsx:270–286 confirm domain-based frontend redirect to SSO when user enters their email and continues. Liveness confirmed (no feature flag).
• Verifier verdict (SCIM not available): PASS — no SCIM endpoint, handler, route, or schema found anywhere in the codebase; WorkOS used solely for SSO authentication.

Uncertainties

None. The added verification step describes the browser-level SSO redirect behavior, which is verified against code. The doc already correctly documents (in the existing bullet points and MFA section) that password-based login is not blocked at the backend — the new paragraph is consistent with that nuance and does not contradict it.

Related observations

• The human agent's answer ("everyone with an @komodohealth.com email will be required to use SSO and won't be able to log in using other methods") is an oversimplification — the doc already correctly notes that password-based login bypasses the SSO redirect. No doc change needed; the nuance is already documented accurately.
• The human agent said SCIM is "considering it for next quarter" — the doc correctly says "on Clay's roadmap" without a timeline promise. No change needed.

Closes DOC-1087